Kiwi Chris

I think it would be useful having a consistent location for documentation features both in the open source part and pro modules, and at what version a given feature was introduced. Sometimes releases are just bug fixes, and depending on what they fix, may or may not be necessary if they're fixing a newer feature that you're not yet using. I use Plesk on my server, and I like the change log they release. It's colour coded with each release for bug fixes, new features, improved functionality, and deprecations, and though it's a long page to scroll through, you can scroll back and see exactly when a feature was introduced or updated. Something like this would be great. I've missed or forgotten about new features as they've got mentioned in a blog post at a time I didn't need them, then later when they'd have been useful, I didn't remember they were there. Documentation for some of the pro modules can be scattered around, and particularly for fieldtypes, but also other pro modules, I think the documentation should live with the main documentation, and might even result in more sales as a result. I think there should be a list of all official fieldtypes, free, and pro, in the documentation section. There's no single point of reference for everything ProcessWire does. The Pro fields seem to be partially included in the API reference, but this is only the API definitions, not general instructions on how to use them.

Agreed. I'd rather have quality over quantity. ProcessWire already works very well, and new features are always nice, but I'm quite happy if they take time to get right before releasing. There was a cheese ad in my country where the catchphrase was 'good things take time', and I think that can apply to anything.

The most popular open source software in the world follows this model, and Linus still gets to have (a highly opinionated) say.

Sites don't remain static, so this site has had a redesign, ProcessWire upgraded, and some new modules installed. There may still be a few glitches, as I want to write content as much as I want to write code, and there are still bits to tidy up, but it's a significant update. I'm now using FormBuilder Pro, and ListerPro to make site management easier.

Sometimes bad stuff happens, and the best way through it is often to keep doing stuff for other people, but it's ok and sometimes necessary to take time out. Four years ago I had to deal with dad's rapid decline and eventual death, while at the same time my wife was diagnosed with breast cancer, and I had to give evidence at a really nasty trial of another family member, where nothing was what it seemed, and I didn't know who to trust. I think a common issue open source projects face is how to keep them open source and pay the developers a decent income. I think AI has only further complicated things, as while it enables individual developers to be much more productive, it also makes it easier for people to do things without needing a developer at all, and can make it harder for content sites to pay their way, so I don't have any easy answers in that respect. I know @bernhard was extremely active in the ProcessWire community and developed some incredibly useful modules like RockMigrations, but he's gone quiet, and I saw a post noting that he hadn't been able to make his ProcessWire efforts pay. Clearly all of us have a stake in ProcessWire being financially sustainable both for Ryan, but also for all of us in our own use of it. I think getting more sites using ProcessWire is important. A large price increase in the pro modules might not help Ryan if fewer people pay for them due to cost, but an increase in the number of people purchasing them would keep them affordable while still generating more revenue. One of the things that makes ProcessWire so much better than WordPress, but may also put WordPress users off, is it doesn't assume how you want to structure your data. That means you can't really do an instant install. I've been thinking for a while about how OO programming itself works with extensible classes, and now that the likes of RocMigrations exists, I wondered about the idea of a base site profile that gives you essentially a brochure site, but then modules that do nothing more than install additional fields and templates, that extend the base profile with additional functionality as required. That might need some naming conventions around field and templates, however if you know that a given module is just going to install some specific fields and templates, it's already baked into ProcessWire the ability to have module dependencies, so rather than checking each and every field and template, you can just check whether a given module that installs them is installed, which might allow building ProcessWire websites almost as quickly as WordPress ones, but still with the ability to keep everything readily customisable and with a consistent UI. I like this in some ways more than site profiles, as with a site profile, you get a fixed set of functionality at install time rather than packs of fields and templates that you can install on top of a base model if you need different functionality. eg, if you know that a given set of modules (that are just wrappers for making certain sets of fields and templates available) are installed, it would make it easier for people to 'theme' them. Once you get a known set of field names that will exist if certain modules are installed, it's easier for people to build themes around them. I already found a snippet that I've used when I wanted to update the appearance of a site to allow testing a new look that I could put in init.php if ($user->isLoggedIn() && $user->hasRole('tester')) { $config->urls->templates = "/site/bootstrap5/"; $config->paths->templates = dirname(__DIR__) . $config->urls->templates; } This could quite easily be modified to allow 'themes' ie different versions of templates while leaving official ones untouched, and could include 'pro' themes. So -> get ProcessWire -> pick the components you want -> pick a theme, and done, with all of it still possible to be done manually, but the possibility to get a site up in a few clicks, and pay for premium components, with the modules functionality almost like an app store. I think having the ability to purchase premium modules built in directly to the admin UI might be helpful too, although it should never be the only way, as people who're concerned about security may prefer the requirement to manually upload new modules, as is the option now. I also wonder about official ProcessWire hosting (maybe combined with specific site profile/module packages that will be kept up to date)? Many other open source projects offer something like that with the option to either use the officially hosted plan or run your own, so there's no compulsion, but it's quick and easy for people to get started.

I've just stumbled on this module, and wonder if it might work for a use case scenario I have in mind? It sounds like this module can handle allowing/denying access to access controlled content via subscription, but I'm thinking of something a bit more flexible. I notice quite a few media sites operate under a 'freemium' model, whereby non paying visitors get ads, and may not have access to some content (sometimes with access after a delay period). Separating public from subscribers is easy enough with ProcessWire roles, but having a way to automatically assign someone a role on payment of a subscription, and revocation of that role when their subscription expires would be useful to have. Adding or removing a role is more flexible rather than just granting or denying access, as it's very easy to write separate logic to decide what happens if someone does/doesn't have a given role, which may not necessarily be to deny access completely, but perhaps inject ads, or show just a page summary instead of full content. Can this module do this, or could it be hooked to do so?

I love that rather than just consuming AI, you're trying to learn how it actually works. Speaking of the translation of code - I wonder if AI would make it easy to provide a PostgreSQL database layer for ProcessWire? Also speaking of C, I wonder about translating the entire ProcessWire codebase into Rust. (It would probably be expensive in terms of token use) ProcessWire is fast as PHP apps go, but Rust is blindingly fast, but harder to learn than PHP. It's also memory safe whereas C isn't. It might not work, as PHP is interpreted so it makes it easy to deploy individual files, whereas Rust compiles to a single binary executable, so it's probably like comparing apples with pumpkins, but all kinds of things ight be possible of you don't have to painstakingly write all the code by hand.

I'd be careful to proofread any blog posts. This week I received an automated email asking me if I'd like to advertise a service I've never offered (but I could see how an AI might infer that I offer it), on a website purporting to be a guide to my region. What the person behind the site didn't know is that I own a site about my region (using ProcessWire obviously), so it was very easy to fact check the new site, and it was immediately obvious it had been entirely AI generated as it was so full of factual errors and included overly enthusiastic promotional styles of writing and checklists that simply didn't read credibly like a human wrote it. Coding with AI is different: You can test whether it does what it's supposed to, but with blog content where it doesn't have to execute, just be read by humans, it pays to check it carefully to ensure it doesn't produce something that's plausible but plain wrong, or worse, a mix of truth and mistruth that can make spotting the mistruth difficult. Using AI to suggest topics for blog posts and give some content ideas is safer, and can be helpful.

It might be some years since this was released, but I've just found how useful this is combined with Repeater Matrix. I was looking at a complex site where the designer had asked for multiple different page layouts and I was trying to figure out how to avoid a chaotic mess of a huge numbers of fields and templates. Repeater Matrix solved half the problem, but working out how to apply the depth information was a different story. This module along with the example gave me the other half of the solution I needed. I'm working with Bootstrap, and it was easy to add a field in my repeater matrix types to specify the css classes for each element and have some types that are basically just containers with no direct content, but contain other blocks.

It turned out the generated RockMigrations code in the UI didn't use IDs, but it did get confused by me defining fields without prefixes in the UI. I found by deleting the duplicate fields that were not editable via the UI, and renaming the ones I wanted to use in a module to include the prefix, that seems to have got things working as expected. I just need to remember that the file name for the field/template for config migrations needs to be without the prefix, otherwise I'd end up with it double prefixed, and the problem would return. eg. Module called mymodule -> field name in UI = mymodule_myfield but file name with definition in mymodule/RockMigrations/fields needs to be just myfield.php The fields need to be renamed before they're added to a module migration. Template definitions in the migration need to use the full prefixed field names, as the template definition doesn't know or care whether the fields are included in the module migration or are in the site migration. After experimenting a bit more, I've found that having some fields/templates just in the site config migrations is a good compromise. It's better than using a site profile, as you can just copy and paste the fields and templates into an existing project even after initial setup. It's not quite as powerful as having the fields and templates in a module, as that provides dependency checking before installing a module that requires them to exist, but that's unlikely to be an issue in my own projects although it could be if I'm distributing modules that depend on certain fields existing.

This would be the ultimate development tool. I understand how it could be difficult to implement, as I found out the hard way with repeaters that if you save all field properties into a migration file it deletes data when applied. So far I haven't experienced anything so catastrophic with any other field types. I wonder if in a migration for a module at least, that's using config migrations, whether it would be possible to define a watch list of fields and templates so that any time these are changed via the GUI, their individual migration file will be updated? They probably would still need some manual editing to remove unnecessary properties, but a good diff tool can do this quickly. I hadn't spotted that before. Very nice feature to avoid having to remember lots of stuff. I think I can remember 'rmf'. 🙂 What happened here is I defined the fields via the UI as normal fields without any prefix, then copied the definitions from the UI into config migration files. When I installed the module, the fields got created, but with prefixes. I will experiment with renaming the fields and templates in the GUI before I add them to config migrations, and see if this gives me just a single copy of each field and template. Do I still need to follow the convention of site/RockMigrations/templates, site/RockMigrations/fields etc? I made the files in a module because I thought config migrations require a module, but if they work at the site level as well, that might be more appropriate. My migrations probably don't need to be part of a module however I started thinking about a website itself like an object. Even the most basic website will probably have certain fields and templates to be functional. Depending on what else it does, it will need additional fields and templates that extend that base. If I decide I want to refine that base, I can do it in one place and apply it to all sites that use it without having to copy and paste any code if I have it defined in a module.

I love the concept of config migrations with each field and template having its own file, as it's much more in line with what I'm used to with ASP.Net Core and Visual Studio where you can build some things visually, but still end up with code, and it's also tidier with version control, as fields or templates that don't change are kept separate. Another benefit I see of using config migrations, is that due to module dependencies, unlike site profiles that are all or nothing, it's possible to define a basic set of fields for a site in a module, even if the module doesn't do much other than install fields and templates, and then you have a working site with some base functionality. If you want additional functionality on some sites but not others, but require certain fields or templates to exist before you add the additional functionality, the module dependency can take care of this. eg, I might start off wanting just a basic site, then want to add a blog, but a blog template will use some of the same fields as the basic site, but I don't want to have to redefine them, just be sure they already exist before I install the blog upgrade. The issue I've struck is an existing project that I've defined fields and templates with using the ProcessWire UI, but now I want to bundle some of them up into a module. The scenario is I've started building what I think is a one-off site, then I realise that different components have the potential to be reused on multiple sites, but exporting a site profile is too inflexible. Here's a screenshot of templates after copying and pasting template data from existing templates into config migrations for two new modules and installing them. As you can see there are duplicate templates, the originals with no prefix, and new ones prefixed with the module name. I want to avoid this, but still like using the ProcessWire UI to design fields and templates, because I'm forgetful and can't remember all the properties and what they do, and I find the UI reminds me, but once I've created or updated a field or template, I want to add it to a migration file so that it's easy to update across multiple sites. Would renaming the templates (same thing applies to fields) to the naming convention of config migrations avoid this doubling up? Also, if I edit one of these apparent duplicate fields, I get this: If I edit the actual "animal" template I get all the usual field editing options, with the normal warning that RockMigrations is installed, although in my config file I've got: $config->noMigrate = true; to prevent rockMigrations overriding changes I make via the ProcessWire UI on my development site, although installing the modules still appears to have triggered the config migrations. Ideally I'd like to avoid what looks like two definitions of the same thing, and still have the UI based editing available. What's the best way to achieve this?

Thanks. This was the problem.

What I can see using Chrome Devtools, is immediately after the subpage is loaded, there's a jquery call to the execute method. What I think is happening is ProcessPageLister is trying to call it's own execute method to load the list, but instead is loading the execute method of the page it's on, resulting in loading the content from the execute() parent page underneath the lister headers. I've set the code to the same as the example that apparently works but it's still resulting in the same issue.

That's weird. I simplified it down to the bare minimum as per the example, and still not working. I wonder if it's some strange third party module interaction? I don't a lot of modules beyond the core loaded, just these: I've tried disabling all autoload modules (other than core) via Tracy debugger, and the problem persists.